1. Field of the Invention
The present invention relates to the field of commerce systems and more particularly to the field of service oriented architected applications.
2. Description of the Related Art
It is now a common trend that traditional, stand-alone, commerce oriented applications are produced from one or more components which can be individually re-used to create business processes for different solutions. Each of these components can expose itself as a set of reusable business functions, also referred to as “services” comporting with computing standards for deploying enterprise level logic that facilitate an open service oriented architecture (SOA). An SOA essentially can be defined as a system where all exposed business and technical functions are in the form of reusable services. These reusable services can communicate with each other to engage either in simple data passing between two or more services, or in activity coordination by two or more services.
In a SOA, a client can invoke an operation on a service to perform a function and, optionally the client can receive a response. Invoked services are generally business functions configured to fulfill the needs of business customers, whether those customers are individual consumers or other businesses. The functions can be grouped into various services where each service can specialize in functions such as catalog management, shopping cart management, credit card transaction processing, sales tax computation and the like. By utilizing an SOA, services in a commerce solution can interoperate with other business processes in a larger commerce solution involving one or more separate business entities and one or more separate consumer entities.
An enterprise service bus (ESB) serves the purpose of simplifying the integration and flexible reuse of business components using an SOA. Generally, an ESB supports the goals of service orientation by enabling the dynamic connection, mediation and control of services and their interactions. In this regard, mediation is an essential capability of an ESB and provides several principal benefits. In particular, mediation allows the ESB to reconcile incompatible protocols, data formats and interaction patterns of connected services. By bridging these differences with the built-in mediation functionality of the ESB, it is much easier to rapidly set up communications among diverse services.
The ESB likewise mediates not just message format and protocol but also interaction patterns, allowing synchronous and asynchronous services to communicate with no changes to the coding of the services. The ability to mediate services without requiring changes to the services eliminates inflexible, hard-coded service interdependencies. In particular, service interdependencies defeat flexibility in that service interdependencies inhibit an understanding of the impact of a service change in an SOA. Thus, by isolating and making explicit the mediation among services, an ESB dramatically facilitates the management of change in a complex environment. The flexibility of mediation can be seen more broadly in that the ESB allow the combination and extension of existing services to meet new requirements. As such, mediated services become general-purpose building blocks which may be orchestrated in order to automate end-to-end business processes.
Mediated services, often referred to as “mediations” can perform repetitive functions including encryption, logging and validation. Oftentimes, the logic for repetitive functions is “cross-cutting” in that the logic of the mediation spans individual components as the function can be applied across multiple different modules. Aspect Oriented Programming (AOP) addresses the problem of cross-cutting logic by allowing the expression of cross-cutting concerns in stand-alone modules termed “aspects”.
However, unlike ordinary cross-cutting logic, a mediation in an ESB must be installed everywhere that the logic of the mediation is to be used. In as much as the mediation can reside in a separate process from the producer and consumer, and further because the mediation can be implemented in a different environment and in a different programming language, AOP cannot be used. Accordingly, the mediation must be installed on each communicative link between consumer or provider and the ESB.